home *** CD-ROM | disk | FTP | other *** search
-
-
-
- DDDDIIIIVVVVOOOOTTTTEEEESSSSTTTT((((1111)))) DDDDIIIIVVVVOOOOTTTTEEEESSSSTTTT((((1111))))
-
-
-
- NNNNAAAAMMMMEEEE
- divotest - DIVO-DVC Diagnostics
-
- SSSSYYYYNNNNOOOOPPPPSSSSIIIISSSS
- ddddiiiivvvvooootttteeeesssstttt [[[[ _o_p_t_i_o_n_s ............]]]]
-
- DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN
- The _d_i_v_o_t_e_s_t program is the diagnostic software for DIVO-DVC ``bring-
- up'', manufacturing verification and burn-in, field service hardware
- diagnosis, and component fault isolation.
-
- Unlike previous video hardware diagnostics, _d_i_v_o_t_e_s_t does not use the IDE
- harness and does not have a ``prompting'' interface. Instead, _d_i_v_o_t_e_s_t
- is driven purely via command-line options.
-
- The output of _d_i_v_o_t_e_s_t is in a standardized format to allow easy parsing
- of results. See the OOOOUUUUTTTTPPPPUUUUTTTT section.
-
- IRIX must be running in order to run _d_i_v_o_t_e_s_t.
-
- EEEEXXXXAAAAMMMMPPPPLLLLEEEE
- To run all standard DIVO-only tests:
-
- ddddiiiivvvvooootttteeeesssstttt ----ddddiiiivvvvoooo
-
- To run all standard DVCPRO-only tests:
-
- ddddiiiivvvvooootttteeeesssstttt ----ddddvvvvccccpppprrrroooo____oooonnnnllllyyyy
-
- OOOOPPPPTTTTIIIIOOOONNNNSSSS
- _d_i_v_o_t_e_s_t options are selected with one of four syntaxes: ``minus''
- options select tests to execute and access to other common options
- (examples: -vip, -forever); ``equal'' options assign values to a _d_i_v_o_t_e_s_t
- parameter (example: REPEAT=2); ``plus'' options which provide access to
- generally undocumented options; and ``minus minus'' options remove tests
- from the selected list of tests to execute.
-
- Generic options.
-
- ----hhhheeeellllpppp Print help message explaining all options and sample
- usage. The test options are printed in the order they
- would be executed relative to each other.
-
- ----ccccoooonnnnttttiiiinnnnuuuueeee Continue testing when a failure occurs. Normal behavior
- is to stop on first failure. The ----ccccoooonnnntttt and ----cccc also work.
-
- ----ffffoooorrrreeeevvvveeeerrrr Loop over the specified tests until interrupted by ctrl-C
- or until a failure occurs (see ----ccccoooonnnnttttiiiinnnnuuuueeee ).
-
- ----iiiinnnnffffoooo Enable output of INFO messages (the default).
-
-
-
-
-
- PPPPaaaaggggeeee 1111
-
-
-
-
-
-
- DDDDIIIIVVVVOOOOTTTTEEEESSSSTTTT((((1111)))) DDDDIIIIVVVVOOOOTTTTEEEESSSSTTTT((((1111))))
-
-
-
- ----nnnnooooiiiinnnnffffoooo Suppress output of INFO messages.
-
- ----nnnnoooottttiiiimmmmeeee Suppress output of TIME messages (the default).
-
- ----ttttiiiimmmmeeee Enable output of TIME messages.
-
- ----ttttrrrraaaacccceeee Enable output of TRCE messages.
-
- ----nnnnoooottttrrrraaaacccceeee Suppress output of TRCE messages.
-
- ----ccccooooddddeeee Enable output of CODE messages (the default).
-
- ----nnnnooooccccooooddddeeee Suppress output of CODE messages.
-
- ----ccccoooolllloooorrrr Colorize RSLT messages (default). Red for FAIL, Green
- for PASS and Yellow for UNRESOLVED.
-
- ----nnnnooooccccoooolllloooorrrr Don't colorize RSLT messages.
-
- ----mmmmeeeettttaaaa Show META lines when testing is completed. META lines
- display accumulated pass/fail statistics.
-
- ----ddddeeeebbbbuuuugggg #### Enable debug messages through level #. Same as DEBUG=#.
-
- DDDDEEEEVVVVIIIICCCCEEEE====#### Selects which DIVO-DVC is to be tested in a system having
- more than one DIVO boards. Default is DIVO board 0.
-
- MMMMOOOODDDDNNNNUUUUMMMM====#### Selects module of which DIVO-DVC device to be tested
- resides. Default is module 1.
-
- SSSSLLLLOOOOTTTTNNNNUUUUMMMM====#### Selects slot of which DIVO-DVC device to be tested
- resides. This is a must for systems with multiple DIVO-
- DVC devices.
-
- MMMMEEEETTTTAAAA====#### Interval of full test loops between META reporting.
-
- DDDDEEEEBBBBUUUUGGGG====#### Enable output of DBUG messages at less than or equal to #
- (where # is between 0 and 9 inclusive). Same as -debug #.
-
- RRRREEEEPPPPEEEEAAAATTTT====#### Number of repetitions through all selected tests.
-
- TTTTRRRRAAAACCCCEEEE====ffffiiiilllleeeennnnaaaammmmeeee Trace file messages logged to named file.
-
- LLLLOOOOGGGG====ffffiiiilllleeeennnnaaaammmmeeee Standard output logged to named file.
-
- TTTTDDDDEEEEBBBBUUUUGGGG====#### Enable trace file output of DBUG messages at less than or
- equal to # (where # is between 0 and 9 inclusive). This
- can be set higher (more debugging) than the DEBUG=#
- option to capture more debugging without obscuring the
- standard output stream.
-
-
-
-
-
- PPPPaaaaggggeeee 2222
-
-
-
-
-
-
- DDDDIIIIVVVVOOOOTTTTEEEESSSSTTTT((((1111)))) DDDDIIIIVVVVOOOOTTTTEEEESSSSTTTT((((1111))))
-
-
-
- Board test suites.
-
- ----ddddiiiivvvvoooo Run all DIVO-only board tests.
-
- ----ffffeeee0000 Run all DIVO-only INPIPE front-end tests.
-
- ----ffffeeee1111 Run all DIVO-only OUTPIPE front-end tests.
-
- ----bbbbeeee0000 Run all DIVO-only INPIPE back-end tests.
-
- ----bbbbeeee1111 Run all DIVO-only OUTPIPE back-end tests.
-
- ----ddddvvvvccccpppprrrroooo____oooonnnnllllyyyy Run all DVC-only tests.
-
- ----ddddvvvvccccpppprrrroooo____iiiinnnnppppiiiippppeeee Run all DVC-only INPIPE tests.
-
- ----ddddvvvvccccpppprrrroooo____oooouuuuttttppppiiiippppeeee Run all DVC-only OUTPIPE tests.
-
- Individual tests. Multiple options can be specified. The union of tests
- for all specified options will be run. Tests are listed here in their
- order of execution (especially true for the output videopipe). We will
- need to figure out the proper test sequence for the input videopipe,
- particularly, for the back-end area.
-
- Note that for the test name, the "0" (zero) is used to denote a test to
- verify a hardware module or component resides on the input pipe, and the
- "1" (one) for a test to verify a hardware module or component resides on
- the output pipe. For example, the ``-linc0sanity'' is to verify the LINC
- sanity on the input pipe while the ``-linc1sanity'' is used on the output
- pipe, but their test functionalities are truly equivalent.
-
- ----nnnniiiicccc Sanity test to verify on-board NIC contents. If this
- part is not programmed properly, the DIVO board will not
- be identified. If this test fails, do not proceed.
-
- ----bbbbrrrriiiiddddggggeeee Test BRIDGE basic functionality. This test verifies the
- BRIDGE identification and part numbers. It also verifies
- several registers and interrupt functionality.
-
- ----lllliiiinnnncccc0000ssssaaaannnniiiittttyyyy oooorrrr ----lllliiiinnnncccc1111ssssaaaannnniiiittttyyyy
- Test LINC0/LINC1 basic functionality. This test verifies
- the LINC device and vendor identification numbers. It
- verifies the LINC Configuration and PIO spaces, the LINC
- PPCI readable/writeable registers, the LINC mailbox mask
- register, the LINC BYTEBUS interface, and the LINC CPCI
- interface.
-
- ----ffffllllaaaasssshhhh0000ssssaaaannnniiiittttyyyy oooorrrr ----ffffllllaaaasssshhhh1111ssssaaaannnniiiittttyyyy
- Host-based test to verify the basic functionality of the
- FLASH0/FLASH1. This test verifies the BYTEBUS accessible
- path to the flashprom part. It also verifies the
- flashprom manufacture and part identifications.
-
-
-
- PPPPaaaaggggeeee 3333
-
-
-
-
-
-
- DDDDIIIIVVVVOOOOTTTTEEEESSSSTTTT((((1111)))) DDDDIIIIVVVVOOOOTTTTEEEESSSSTTTT((((1111))))
-
-
-
- ----ssssddddrrrraaaammmm0000 oooorrrr ----ssssddddrrrraaaammmm1111
- Host-based test to stress the SDRAM0/SDRAM1. On each
- pipe test the SDRAM by (1) using unique data patterns as
- data, (2) using addresses and inversed addresses as data,
- and (3) walking across the SDRAM address bus.
-
- ----lllliiiinnnncccc0000mmmmbbbbooooxxxx oooorrrr ----lllliiiinnnncccc1111mmmmbbbbooooxxxx
- Host-based test to verify the LINC0/LINC1 mailbox
- functionality. There are 32 individual mailboxes in each
- LINC. This test writes to each LINC mailbox with a known
- value, verifies that the CHG bit is set after each
- mailbox write, and then verifies data in the BUFMEM match
- with the written values.
-
- ----lllliiiinnnncccc0000ddddmmmmaaaa oooorrrr ----lllliiiinnnncccc1111ddddmmmmaaaa
- Host-based test to verify the LINC0/LINC1 DMA
- functionality. On the input pipe (hence INPIPE) this
- test performs and verifies the DMA transfers between
- LINC0 DMA0 to host, between LINC0 DMA1 to host, between
- host to LINC0 DMA0, and finally between host to LINC0
- DMA1. On the output pipe (hence OUTPIPE) this test
- performs and verifies the DMA transfers between LINC1
- DMA0 to host, between LINC1 DMA1 to host, between host to
- LINC1 DMA0, and finally between host to LINC1 DMA1. Each
- DMA transfer consists of a one-page 16 kilobytes of
- stressful and known data.
-
- ----lllliiiinnnncccc0000iiiiddddmmmmaaaa oooorrrr ----lllliiiinnnncccc1111iiiiddddmmmmaaaa
- Host-based test to verify the LINC0/LINC1 IDMA
- functionality. On the input pipe (hence INPIPE) this
- test performs and verifies the IDMA transfers between
- LINC0 IDMA to host, and between host to LINC0 IDMA. On
- the output pipe (hence OUTPIPE) this test performs and
- verifies the IDMA transfers between LINC1 IDMA to host,
- and between host to LINC1 IDMA. For the read mode (hence
- host to LINC), the IDMA transfer consists of 128 bytes of
- known test patterns. For the write mode (hence LINC to
- host), the IDMA transfer consists of an 8 bytes of known
- test patterns.
-
- ----ccccppppcccciiiissssaaaannnniiiittttyyyy0000 oooorrrr ----ccccppppcccciiiissssaaaannnniiiittttyyyy1111
- Test INPIPE/OUTPIPE VIP basic functionality. This test
- verifies the VIP device and vendor identifications, the
- VIP Configuration space, and some VIP internal registers.
- it also verifies the VIP UST logic functionality.
-
- ----rrrrppppcccc0000ssssaaaannnniiiittttyyyy oooorrrr ----rrrrppppcccc1111ssssaaaannnniiiittttyyyy
- Verify the Xilinx program is loaded successfully on
- INPIPE/OUTPIPE RPC. Note that this test assumes that the
- appropriate RPC Xilinx code has already been loaded into
- the INPIPE/OUTPIPE RPC.
-
-
-
-
- PPPPaaaaggggeeee 4444
-
-
-
-
-
-
- DDDDIIIIVVVVOOOOTTTTEEEESSSSTTTT((((1111)))) DDDDIIIIVVVVOOOOTTTTEEEESSSSTTTT((((1111))))
-
-
-
- ----vvvv0000vvvviiiiddddddddmmmmaaaa oooorrrr ----vvvv1111vvvviiiiddddddddmmmmaaaa
- Verify INPIPE/OUTPIPE VIP non-compressed video dma
- functionality. For the INPIPE mode, the video dma test
- sequence is as follows: (1) initialize 8 SDRAM-based
- buffers for the video data, (2) set up and enable the
- video dma direction for INPUT mode, (3) program the video
- dma address with the destination address, (4) queue 1
- video dma command and when the transmit command is
- enabled, the transfer happens immediately, (5) during
- this process the RPC starts pushing the video data
- upstream until the desired data to be transfered are
- exhausted, (6) repeat steps 3 through 5 until all 8 video
- dma cmds are exhausted, and (7) verify the transfer
- status, the data being transfered, and the video CRCs.
- For the OUTPIPE mode, the test sequence is similar to the
- INPIPE except that the test is programmed to execute in
- OUTPIPE mode.
-
- ----ssss0000vvvviiiiddddddddmmmmaaaa oooorrrr ----ssss1111vvvviiiiddddddddmmmmaaaa
- Verify INPIPE/OUTPIPE VIP strided video dma
- functionality. For both INPIPE or OUTPIPE mode the test
- sequence is similar to the non-compressed video dma test
- except that in this case different striding modes are set
- for the strided transfer. The intent is to verifies the
- VIP various striding functionalities by using different
- stride skips, lengths, and offsets for the overall dma
- settings.
-
- ----rrrr0000vvvviiiiddddddddmmmmaaaa oooorrrr ----rrrr1111vvvviiiiddddddddmmmmaaaa
- Verify INPIPE/OUTPIPE VIP compressed video dma
- functionality. For both INPIPE or OUTPIPE mode the test
- sequence is similar to the non-compressed video dma test
- except that in this case the test is programmed to
- utilize the embbeded RICE path localized in the VIP.
- During the process the test also verifies the RICE
- code/decoder. After the last transfer of many transfers,
- the test verifies the overall dma status, the data being
- transfered, and the CRCs.
-
- ----vvvv0000aaaauuuuddddddddmmmmaaaa oooorrrr ----vvvv1111aaaauuuuddddddddmmmmaaaa
- Verify INPIPE/OUTPIPE VIP audio dma functionality. For
- the INPIPE mode, the audio dma test sequence is as
- follows: (1) initialize 8 SDRAM-based buffers for the
- audio data, (2) set up and enable the audio dma direction
- for INPUT mode, (3) program the audio dma address with
- the destination address, (4) queue 1 audio dma command
- and when the transmit command is enabled, the transfer
- happens immediately, (5) repeat steps 3 and 4 until all 8
- audio dma cmds are exhausted, and (6) verify the transfer
- status, the data being transfered, and the CRCs. For the
- OUTPIPE mode, the test sequence is similar to the INPIPE
- except that the test is programmed to execute in OUTPIPE
-
-
-
- PPPPaaaaggggeeee 5555
-
-
-
-
-
-
- DDDDIIIIVVVVOOOOTTTTEEEESSSSTTTT((((1111)))) DDDDIIIIVVVVOOOOTTTTEEEESSSSTTTT((((1111))))
-
-
-
- mode.
-
- ----vvvv0000vvvviiiittttccccddddmmmmaaaa oooorrrr ----vvvv1111vvvviiiittttccccddddmmmmaaaa
- Verify INPIPE/OUTPIPE VIP single-line and dual-line VITC
- dma functionality. For the INPIPE mode, the VITC dma
- test sequence is as follows: (1) initialize 1 SDRAM-
- based buffer for the VITC data, (2) set up and enable the
- VITC dma direction for INPUT mode, (3) program the VITC
- dma address with the destination address, (4) queue the
- single-line VITC dma command and when the transmit
- command is enabled, the transfer happens immediately, (5)
- verify the transfer status, the data being transfered,
- and the CRCs. Then repeat steps 1 through 5 but this
- time set to do the dual-line VITC dma. For the OUTPIPE
- mode, the test sequence is similar to the INPIPE except
- that the test is programmed to execute in OUTPIPE mode.
-
- ----ccccccccdddd0000UUUUffffuuuunnnncccc oooorrrr ----ccccccccdddd1111UUUUffffuuuunnnncccc
- Verify INPIPE/OUTPIPE overlapping dma functionality. The
- overlapping dmas are consisted of uncompressed video,
- audio, and VITC dma commands.
-
- ----ccccccccdddd0000SSSSffffuuuunnnncccc oooorrrr ----ccccccccdddd1111SSSSffffuuuunnnncccc
- Verify INPIPE/OUTPIPE overlapping dma functionality. The
- overlapping dmas are consisted of uncompressed and
- strided video, audio, and VITC dma commands.
-
- ----ccccccccdddd0000RRRRffffuuuunnnncccc oooorrrr ----ccccccccdddd1111RRRRffffuuuunnnncccc
- Verify INPIPE/OUTPIPE overlapping dma functionality. The
- overlapping dmas are consisted of compressed video,
- audio, and VITC dma commands.
-
- ----ddddvvvvccccpppprrrrooooccccppppcccciiii0000 oooorrrr ----ddddvvvvccccpppprrrrooooccccppppcccciiii1111
- Verify DVC daughter card's INPIPE/OUTPIPE VIP basic
- functionality. This test verifies the VIP device and
- vendor identifications, the VIP Configuration space, and
- some VIP internal registers.
-
- ----ddddvvvvccccpppprrrroooovvvviiiiddddiiiiffff0000 oooorrrr ----ddddvvvvccccpppprrrroooovvvviiiiddddiiiiffff1111
- Verify DVC daughter card's INPIPE/OUTPIPE VIDIF XILINX
- functionality. Ucode is loaded to the Xilinx.
-
- ----ddddvvvvccccpppprrrrooooccccsssscccc0000 oooorrrr ----ddddvvvvccccpppprrrrooooccccsssscccc1111
- Verify DVC daughter card's INPIPE/OUTPIPE CSC basic
- register functionality.
-
- ----ddddvvvvccccpppprrrrooooiiii2222cccceeeennnncccc oooorrrr ----ddddvvvvccccpppprrrrooooiiii2222ccccddddeeeecccc
- Verify DVC daughter card's INPIPE/OUTPIPE I2C basic
- functionality.
-
-
-
-
-
-
- PPPPaaaaggggeeee 6666
-
-
-
-
-
-
- DDDDIIIIVVVVOOOOTTTTEEEESSSSTTTT((((1111)))) DDDDIIIIVVVVOOOOTTTTEEEESSSSTTTT((((1111))))
-
-
-
- OOOOUUUUTTTTPPPPUUUUTTTT
- The output format is line based. Lines are no more than 80 characters in
- length. Each line is tagged by one of the following four-character
- identifiers:
-
- TTTTEEEESSSSTTTT Test start markers, generated at the beginning of a test.
- Indicates the test's symbolic name and description. All
- following lines up to the next TEST line are associated with the
- named test.
-
- Columns 1- 4: "TEST"
- Columns 6-19: test symbolic name
- Columns 21-80: test description
-
- RRRRSSSSLLLLTTTT Test result, generated at the end of a test. Indicates the
- test's symbolic name and the test result. The result will be one
- of pass, fail, unresolved, or untested.
-
- Columns 1- 4: "RSLT"
- Columns 6-19: test symbolic name
- Columns 21-30: "PASS" | "FAIL" | "UNRESOLVED" | "UNTESTED"
- Columns 41-80: optional short explanation
-
- DDDDIIIIAAAAGGGG Diagnosis message. One or more of these lines will preceed any
- fail or unresolved message. The message should indicate what
- components or wires are possible causes of the failed test.
-
- Columns 1- 4: "DIAG"
- Columns 21-80: diagnosis message
-
- IIIINNNNFFFFOOOO Information which is useful to an advanced user of the
- diagnostic. This can include test progress reports, exp/rcv
- pairs, etc. INFO messages are enabled by the ----iiiinnnnffffoooo command line
- option.
-
- Columns 1- 4: "INFO"
- Columns 21-80: informational message
-
- DDDDBBBBUUUUGGGG Debugging information, only generated when debugging output is
- turned on (not the default); not intended for field or
- manufacturing use but may be useful to diagnostic programmers.
- DBUG messages are enabled by the ----ddddeeeebbbbuuuugggg command line option.
-
- Columns 1- 4: "DBUG"
- Column 6: debugging level, one through nine
- Columns 21-80: debugging message
-
- TTTTIIIIMMMMEEEE Time stamp, generated at important time boundaries such as the
- beginning and end of divotest.
-
- Columns 1- 4: "TIME"
- Columns 6-33: Unix style date
-
-
-
- PPPPaaaaggggeeee 7777
-
-
-
-
-
-
- DDDDIIIIVVVVOOOOTTTTEEEESSSSTTTT((((1111)))) DDDDIIIIVVVVOOOOTTTTEEEESSSSTTTT((((1111))))
-
-
-
- MMMMEEEETTTTAAAA Summarizes information over several tests. A table is generated
- providing the pass and fail counts of each test (and totals over
- all tests) across multiple full test loops.
-
- Columns 1- 4: "META"
- Columns 21-80: summary statistics
-
- NNNNSSSSHHHHPPPP Indicates the hardware has down-rev parts, an unsupported
- configuration, or is otherwise not fit for shipping to customers.
-
- Columns 1- 4: "NSHP"
- Columns 21-80: explanation
-
- AAAABBBBRRRRTTTT Reports an exceptional error condition leading to the abortion of
- the diagnostics. Probably caused by a malloc failure, unexpected
- system call failure, or assertion failure. Should not happen
- under normal circumstances.
-
- Columns 1- 4: "ABRT"
- Columns 21-80: abort explanation
-
- CCCCOOOODDDDEEEE Encodes board and ASIC failures for easy parsing. CODE messages
- are enabled with the -code command line option. There are
- several sub-options based on columns 21-24. Each of these is
- listed below.
-
- Columns 1- 4: "CODE"
- Columns 6-19: test symbolic name
-
- either
-
- Columns 21-24: "BF" - indicates board failure for a given test
- Column 25: "R" | "Y" | "G" - board status (Red, Yellow, or
- Green)
- Columns 27- : <Part Number>":"<Serial Number>"("<NIC
- Number>")@"<ASIC list>
-
- or
-
- Columns 21-24: "SUM" - overall execution summary
- Columns 25-80: "No error" | "Hardware error"
-
- or
-
- Columns 21-24: "BSUM" - error summary for a board
- Columns 26-28: Number of tests showing "R"ed status
- Column 29: "R"
- Columns 30-33: Number of tests showing "Y"ellow status
- Column 34: "Y"
- Columns 35-38: Number of tests showing "G"reen status
-
-
-
-
-
- PPPPaaaaggggeeee 8888
-
-
-
-
-
-
- DDDDIIIIVVVVOOOOTTTTEEEESSSSTTTT((((1111)))) DDDDIIIIVVVVOOOOTTTTEEEESSSSTTTT((((1111))))
-
-
-
- Column 39: "G"
- Columns 41- : <Part Number>":"<Serial Number>"("<NIC Number>")"
-
- or
-
- Columns 21-24: "CSUM" - always follows "BSUM" and indicates chip
- failures on the given board.
- Columns 26-28: Number of tests showing "R"ed status
- Column 29: "R"
- Columns 30-33: Number of tests showing "Y"ellow status
- Column 34: "Y"
- Columns 35-38: Number of tests showing "G"reen status
- Column 39: "G"
- Columns 41- : Name of Chip
-
- FFFFIIIILLLLEEEESSSS
- /usr/diags/DIVO/bin/divotest executable for DIVO diagnostics.
- /usr/diags/DIVO/ucode directory of DIVO RPC diagnostic microcode.
- /usr/diags/DIVO/data directory of data files for DIVO
- diagnostics.
- /usr/diags/DIVO/scripts directory of invokable scripts for DIVO
- diagnostics.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- PPPPaaaaggggeeee 9999
-
-
-
-
-
-
- DDDDIIIIVVVVOOOOTTTTEEEESSSSTTTT((((1111)))) DDDDIIIIVVVVOOOOTTTTEEEESSSSTTTT((((1111))))
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- PPPPaaaaggggeeee 11110000
-
-
-
-
-
-
-